Business

Google promises to play nice with ad blockers (again)

Google relaxes control on new Chrome extensions API that would have crippled ad blockers.

Written by Catalin Cimpanu, Contributor June 12, 2019 at 5:13 p.m. PT

TechRepubli

10 things you should never do in Excel

After being ripped to shreds by angry users, Google engineers have promised today that the upcoming changes to Chrome's extensions system won't cripple ad blockers, as everyone is fearing.

Instead, the company claims that the new extension API changes will actually improve user privacy and bring speed improvements.

Furthermore, Google also promised to raise a maximum limit in one of the upcoming APIs that should address and lay to rest the primary criticism brought against the new extensions API by developers of ad blockers during the last six months.

The beginning

All of this drama about "Google crippling ad blockers" started back in October 2018, when Google announced major changes to the Chrome extensions ecosystem.

Plagued by a rise in the number of malicious extensions, Google announced new rules for the extensions review process, but also major changes to Chrome's extensions codebase.

Google grouped the changes in the Chrome codebase in a new set of rules called Manifest V3, which developers had to follow when coding new extensions or updating old ones to work with Chrome's future codebase.

All of the Manifest V3 changes were detailed in a 19-page "design document" that the browser maker published last year.

The old Web Request API

While initially there was little discussion about the Manifest V3 changes, in January, the maintainers of several ad blocker extensions raised an issue with the deprecation of the Web Request API, which they were using to inspect web requests before a page was loaded inside the browser.

Developers were angry that Google was replacing this tried and tested feature with one named the Declarative Net Request API, which they said would prevent their extensions from inspecting web requests made on a page with the same efficiency as the older API.

The original Web Request API allowed developers to stop a page from loading while they looked at the page's content to search for ads or other content, and block or modify it as they wished.

Google said today that this old API was a source of abuse, with 42% of all the malicious extensions the company detected since January 2018, abusing it for nefarious purposes.

"With Web Request, Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails," Simeon Vincent, Developer Advocate for Chrome Extensions, said today.

The privacy risk is obvious and apparent.

"Because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user's credentials, accounts, or personal information," Vincent said.

The Declarative Net Request API

Instead, Google planned to replace this old and security-proned API with one that worked very differently.

Named the Declarative Net Request API, this new technology would work the exact opposite. Instead of an extension stopping web requests and looking at all the content, the extension sets up "rules" that the browser reads and applies to each web page before it loads.

With this new API, extensions never receive page data, and the browser makes all the modifications to a page only when one or more declared "rules" are met.

This way, all the user's data that may be included on a page -- such as emails, photos, passwords, etc. -- remain at the browser level, and are never passed to the extensions.

Declarative Net Requests API — Image: Google

Google says the new API is better in terms of privacy, but also speed, as Chrome's highly optimized code handles all the web request filtering, instead of leaving this operation to an extension's slow JavaScript code.

The problem

But in January this year, ad blocker developers argued that despite the advantages of this new API, Google planned to restrict the maximum number of "rules" to 30,000, a number that was far insufficient for ad blockers, which often have to filter web requests for hundreds of thousands of ad-related domains.

In online discussions regarding the upcoming API changes, some argued that a maximum "rules" limit of anywhere between 90,000 to 150,000 would have been enough, while some argued that the rule should be around 500,000, to ensure that ad blockers are completely safe.

Google developers initially disagreed, but today, the company finally relented and promised to update the "rules" limit to 150,000, from the current 30,000.

Should we trust Google this time?

But this is actually the second time that Google gives in. The company first promised to back down in mid-February, when it said it wouldn't completely remove the Web Request API.

That turned to be a misleading statement, because, in May, Google revealed that it was keeping the Web Request API, but only for enterprise users, and not for regular ones.

At the technical and theoretical level, Google's latest announcement should allow ad blockers to work on top of the new Declarative Net Request API; however, it remains to see if Google keeps its promise this time, and won't have its fingers crossed behind its back like it did in February.

Other issues

Further, some issues still remain. The primary of these is in relation to the capability of the new API. The old Web Request API allowed extensions to be in full control of how they filtered content.

According to previous statements made by the developers of the NoScript and uBlock Origin extensions, the new API's declarative rules system doesn't provide the same level of control.

"I actually don't care about the hard-coded limit on blacklists because I use a whitelist, but I need contextual information which the Declarative API's stated purpose is keeping away from extensions," Giorgio Maone, the developer of the NoScript extension told ZDNet today.

What this means is that extensions that deal with web requests manipulation will most likely lose some of their accuracy in identifying the domains they want to block, and the circumstances they block or allow content to load.

Google engineers don't seem to like the idea of giving extension developers full control, as this would negate any performance impact the new API would introduce.

While the new Manifest V3 is still up for debate, there will be a tug-of-war between the two sides over the coming weeks.

However, Google has given in to various developer requests since January and has also promised today to look into other extension developer gripes.

More on the technical side of the changes Google is currently considering allowing into Manifest V3 can be found in Google's recent blog post on the matter.

All the Chromium-based browsers

More browser coverage:

Editorial standards

Show Comments